Shareware Grab Bag/Shareware Grab Bag.iso/081/opushelp.arc/OPUSHELP.DOC

Text File | 1987-07-28 | 7KB | 198 lines

                    Opus 1.0 Simple Help Documentation
                                    by
                        Bob Hartman (node 132/101)

In the  past 2  1/2 weeks I have received a lot of phone calls and messages
about problems  that people  have had  with oMMM and/or Opus 1.0 (or 1.01),
and I decided that I would finally create a document to help matters just a
bit.   Below you  will find some problems, then the solutions for them.  If
you have something that isn't answered here, please send a message to David
Finster at OpusInfo (node 124/111 primary address).

Problem #1:

     I am not sending out ARCmailed packets like I am supposed to.

Solution:

     You need  to have one of the following statements in your oMMM control
     file:   ArcTo, Hold,  Crash.  All three do ARCmailing, and the keyword
     used determines  whether it  will be  a normal  ARCmail file,  a  held
     ARCmail file, or a Crash ARCmail file.

Problem #2:

     I am trying to poll a node, but I call his network host instead.

Solution:

     You are  probably using  something  like  the  following  sequence  of
     statements:

          POLL x/y
          ...
          ROUTE

     What you  are doing  is creating a .OUT file (via the POLL statement),
     but then  you are  host-routing the  .OUT file  when you use the ROUTE
     statement.   The trick  is to  make the  .OUT file into something else
     that will not be ROUTE'd.  Try the following:

          POLL x/y
          DIRECT x/y
          ...
          ROUTE

     This way  the .OUT file is converted into a .DUT file before the ROUTE
     statement gets  executed.   ROUTE (like most other oMMM control verbs)
     only works on .OUT type files.

Problem #3:

     My nodes that I hold for are having their messages lost.

Solution:

     This can happen a couple of ways, but the most common that I have seen
     is the case where there is a line in the oMMM control file like:

          HOLD x/y a/b c/d ...

     If you  read the  documentation  carefully  you  will  see  that  this
     statement causes  mail for  a/b, c/d  and the  rest to be placed in an
     archive that  is held for node x/y.  What you really want is something
     like:

          NormHold x/y a/b c/d ...
     The above  statement is  used if  you  do  not  want  to  ARCmail  the
     messages, if you do want to ARCmail them, then use:

          OneHold x/y a/b c/d ...

Problem #4:

     My forced  Z-event for  sending only  crash mail  does not  seem to be
     working properly.

Solution:

     This is  a particulary  nasty problem.   As  far as  I can tell (and I
     might be wrong on this, but it seems to hold as far as I can test it),
     a FORCED event will happen EXACTLY ONCE.  So, lets say that you have a
     forced Z-event that runs from 1:00-3:00.  At 1:00 it runs and converts
     you to  a crash  only system.   Now  at 2:00 you exit the system to do
     some maintenance  and start  it up again.  Well, your forced event has
     already taken  place, and  won't be  done again.   You end up with the
     default Z  event from  your control  file.   The  solution  is  rather
     simple:

          Z-events should NEVER BE FORCED events.

     This way  they simply  get noticed  whenever Opus  is checking on what
     event it  is executing,  and the change will take place.  Like I said,
     this one is particulary nasty since it sort of goes against the normal
     train of thought.

Problem #5:

     My system  does not  seem to unpack any mail packets that it receives.
     I see  the .PKT  files in  the inbound  file area,  but  then  nothing
     happens to them.  I use FastToss (or ConfMail) to toss the rest of the
     echomail, but still the .PKT files remain.

Solution:

     Unfortunately, it  appears that  Opus will  only unpack  mail  if  the
     switch to  Extract ARCmail  or the switch to Toss Echomail is enabled.
     If you  don't use  FastToss or  ConfMail, then the solution is just to
     enable one of those options.  If you do use FastToss or ConfMail, then
     the following batch file workaround should do the trick:

          COPY inbound_dir\*.PKT opus_root_dir
          DEL  inbound_dir\*.PKT
          FastToss -N -A   or   ConfMail Import -N -A

     This will move those .PKT files to a location where either FastToss or
     ConfMail will be able to extract them.

Problem #6:

     My events are executing at the wrong times.

Solution:

     This is  caused by an improper setting of the TZ environment variable.
     Set your  system clock  to the  same time as the clock on the wall and
     experiment with  the TZ  environment variable.   Currently  we are  in
     Daylight Savings Time, and TZ=EDT4 works here on the East coast.

Problem #7:

     I can't exit from the C)hange menu.
Solution:

     This is caused by having the Opus 0.0 privilege files in place instead
     of the  Opus 1.0  privilege files.   You  will  need  to  replace  the
     CHGPRIV.BBS file.   Another  method that  I have heard will work is to
     get into  the !)Sysop  menu and  alter the  privileges for the C)hange
     menu.   When Opus  re-writes the file it is in the proper format again
     (supposedly - you would have to try this yourself to verify it).

Problem #8:

     I can't get Wxmodem or CKermit to work with Opus 1.0.

Solution:

     You are  quite correct.  Wxmodem and CKermit were flakey at best under
     Opus 0.0,  and officially  are not  even supported there.  There is no
     new Wxmodem  for Opus  1.0, but  there is  a new  Kermit in  the  file
     OKER_100.ARC.   It uses the new external program interface provided by
     Opus and described in the file OREF_EXT.ARC available from 150/1.

Problem #9:

     I can't  X)port messages  from the  Matrix area,  but I can from other
     areas.

Solution:

     Use the !)Sysop menu to change privileges in the M)atrix menu.

Problem #10 (a late addition):

     My HOLD  statement doesn't  seem to  be having any affect.  I have the
     following in my oMMM control file:

          ArcTo x/y
          Hold x/y

Solution:

     You are  running into the problem of dealing with oMMM as a sequential
     processor.   Both ArcTo,  and Hold  create ARCmail for the given node.
     Since the ArcTo statement is executed first, there is nothing left for
     the Hold statement to work on.  There are two possible ways around the
     problem:

          Hold x/y

     Which does  what you want the above two to do anyway.  Or, if you need
     to do some more processing between the statements, perhaps:

          ArcTo x/y
          ...
          NormHold x/y